Skip to content

chore(deps): update overrides hono to v4.12.27 [security] - #58

Closed
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/npm-hono-vulnerability
Closed

chore(deps): update overrides hono to v4.12.27 [security]#58
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/npm-hono-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
hono (source) 4.12.18 → 4.12.27 age confidence

Hono: JWT middleware accepts any Authorization scheme, not only Bearer

CVE-2026-47673 / GHSA-f577-qrjj-4474

More information

Details

Summary

The jwt and jwk middlewares do not verify that the Authorization header value uses theBearer scheme. Any two-part header value — regardless of the scheme name in the first position — proceeds to JWT verification. A request presenting a valid JWT under a non-Bearer scheme identifier (such as Basic or Token) is authenticated identically to a correctly formed Bearer request.

Details

When processing an Authorization (or custom) header, the middleware splits the value on whitespace and uses the second token as the JWT to verify. It does not check that the first token is bearer (case-insensitively). RFC 6750 specifies that JWT bearer tokens must be presented using the Bearer scheme; other scheme identifiers carry distinct semantics and may be subject to different policies in network-layer security controls.

This discrepancy means that scheme-aware external controls — such as WAF rules, API gateways, or reverse proxies that apply policies specific to the Bearer scheme identifier — can be bypassed by presenting a valid JWT under a different scheme name.

This issue affects hono/jwt and hono/jwk middleware.

Impact

An attacker who possesses a valid JWT may present it under a non-Bearer scheme identifier and still pass middleware authentication.

This may lead to:

  • Bypass of network-layer security controls that inspect or filter requests based on the authorization scheme identifier
  • Token reuse across authentication schemes in applications that use multiple authorization mechanisms

This issue affects applications where hono/jwt or hono/jwk authentication is combined with external controls that enforce scheme-based access policies.

Severity

  • CVSS Score: 4.8 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Hono: IP Restriction bypasses static deny rules for non-canonical IPv6

CVE-2026-47674 / GHSA-xrhx-7g5j-rcj5

More information

Details

Summary

The ip-restriction middleware (hono/ip-restriction) compares incoming IP addresses against configured deny and allow rules using string equality after partial normalization. Non-canonical IPv6 representations of an address already listed in a static rule — such as compressed forms, explicit-zero forms, or hex-notation IPv4-mapped addresses — do not match the normalized rule entry, causing the rule to be silently skipped.

Details

When the rule matcher is built, each configured IP rule is normalized to a canonical string form. Incoming IP addresses received at request time are then compared against those canonical strings without applying the same normalization. Because IPv6 permits multiple syntactically different representations of the same numeric address, a non-canonical form of a denied address fails the string lookup and proceeds to the CIDR check, which also finds no match for rules registered as static (no prefix length). The request is then allowed.

Affected non-canonical forms include:

  • Compressed versus expanded notation (2001:db8::1 vs 2001:db8:0:0:0:0:0:1)
  • Hex-notation IPv4-mapped addresses (::ffff:7f00:1 vs ::ffff:127.0.0.1)
  • Zone identifier suffixes (e.g., fe80::1%eth0)

Additionally, invalid IP address strings provided as the remote address are not rejected and may result in unexpected allow or deny behavior.

This issue arises when applications use ipRestriction() with static (non-CIDR) rules and the IP address source can supply addresses in non-canonical IPv6 form.

Impact

A request from an IP address covered by a static deny rule may bypass the restriction if the address is presented in a non-canonical IPv6 form.

This may lead to:

  • Unauthorized access to endpoints intended to be restricted to specific IP addresses
  • Bypass of IP-based access controls in environments where the runtime or an upstream proxy provides source addresses in a form that differs from the canonical form used in the rule configuration

This issue affects applications using hono/ip-restriction with static deny rules for IPv4 or IPv6 addresses, particularly when the source address is derived from proxy headers or custom getIP implementations that may return non-canonical forms.

Severity

  • CVSS Score: 5.3 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Hono: app.mount() strips mount prefix using undecoded path, causing incorrect routing for percent-encoded paths

CVE-2026-47676 / GHSA-2gcr-mfcq-wcc3

More information

Details

Summary

app.mount() strips the mount prefix from the incoming request path using the raw URL pathname, while route matching is performed against the percent-decoded path. This inconsistency causes the prefix to be stripped at the wrong position when the path contains percent-encoded multi-byte characters, resulting in the mounted sub-application receiving an incorrect path.

Details

When app.mount(prefix, subApp) is called, Hono calculates the number of characters to strip based on the decoded mount prefix length, but then applies that slice to the raw URL pathname. When the URL contains percent-encoded characters that expand to fewer characters when decoded (such as encoded non-ASCII characters), the two representations have different lengths, so the prefix is stripped at the wrong byte offset.

As a result, the sub-application receives a path that does not correspond to the intended sub-path — it may receive a partial or garbled path instead of the expected value after the mount prefix is removed.

This issue arises when an application uses app.mount() with paths that contain percent-encoded characters, particularly when the mount prefix itself or the request path contains encoded non-ASCII characters.

Impact

A mounted sub-application may receive an incorrectly stripped path, causing requests to be routed to unintended handlers within the sub-application.

This may lead to:

  • Middleware or route handlers in the sub-application being bypassed or incorrectly matched due to the malformed path
  • Requests reaching sub-application routes that the developer did not intend to be accessible via the mounted path

This issue affects applications that use app.mount() where the request URL may contain percent-encoded characters in the mount prefix or subsequent path segments.

Severity

  • CVSS Score: 5.3 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Hono: Cookie helper does not sanitize sameSite and priority, allowing Set-Cookie injection

CVE-2026-47675 / GHSA-3hrh-pfw6-9m5x

More information

Details

Summary

The serialize() function in hono/cookie validates domain and path options against characters that corrupt Set-Cookie header syntax (;, \r, \n), but does not apply the same validation to sameSite and priority. An application that passes user-controlled input into either option may produce a Set-Cookie response header containing attacker-chosen additional attributes.

Details

When constructing a Set-Cookie header value, serialize() appends the sameSite and priority option values directly into the output string after a presentation-only transformation (capitalizing the first character). Although the TypeScript type signature constrains these options to specific string literals, that constraint is not enforced at runtime; any string value, including one containing ; or line-feed characters, passes through unchanged.

The validation guard that rejects ;, \r, and \n from domain and path is not applied to sameSite or priority. An application that passes a request-derived value to either option therefore provides an injection point into the header line.

This issue arises when an application passes user-controlled input to the sameSite or priority option of setCookie() or serialize().

Impact

An attacker who can control the sameSite or priority option value may inject additional attributes into a Set-Cookie response header.

This may lead to:

  • Cookie attribute injection — overriding Domain, Path, HttpOnly, Secure, or Max-Age for the affected cookie
  • HTTP response header injection on runtimes that do not strictly validate header values, enabling a second attacker-controlled Set-Cookie header in the same response

This issue affects applications that pass user-derived input into the sameSite or priority option of hono/cookie serialization functions.

Severity

  • CVSS Score: 4.3 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

hono: AWS Lambda adapter merges multiple Set-Cookie headers into one value, dropping cookies on ALB single-header and Lattice

CVE-2026-54287 / GHSA-j6c9-x7qj-28xf

More information

Details

Summary

On AWS Lambda, the ALB single-header response and the VPC Lattice v2 response join multiple Set-Cookie headers into one comma-separated value. Because commas also appear inside cookie attributes (for example Expires dates), clients cannot split the value back into individual cookies and silently drop or misparse them.

Details

Per RFC 6265, each cookie must be its own Set-Cookie header line, and commas may appear inside attribute values. Joining cookies with ", " collides with those commas, producing a value that clients cannot reliably split. Only ALB single-header mode and VPC Lattice v2 are affected; API Gateway v1/v2 and ALB with multi-value headers enabled already use an array and are unaffected.

Impact

A client may receive only one of the cookies, a malformed cookie, or none. Session, CSRF, or preference cookies can silently fail to apply, breaking sessions or forcing re-authentication. This affects applications that set multiple cookies per response and run on AWS Lambda behind an ALB in single-header mode (the default) or VPC Lattice v2.

Severity

  • CVSS Score: 5.3 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

hono: Path traversal in serve-static on Windows via encoded backslash (%5C)

CVE-2026-54286 / GHSA-wwfh-h76j-fc44

More information

Details

Summary

On Windows hosts, an encoded backslash (%5C) in the request path decodes to \, which the Windows path resolver treats as a separator. serve-static then resolves a single URL segment such as admin\secret.txt into a nested file under the root and serves it, letting an attacker read static files meant to be protected behind prefix-mounted middleware. Directory escape (..) remains blocked.

Details

The router splits paths only on /, so /admin%5Csecret.txt is one segment and middleware on /admin/* does not run. The serve-static guard rejects ./.. and consecutive separators but lets a lone \ through; on Windows the file resolver re-splits it into the protected subtree.

This affects Windows hosts serving static files via the Node, Bun, or Deno adapters that guard a static subtree with prefix-mounted middleware.

Impact

An unauthenticated attacker can read static files under a middleware-guarded prefix on Windows hosts. The read stays within the configured root; escape outside the root is not possible.

Severity

  • CVSS Score: 5.9 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

hono: CORS Middleware reflects any Origin with credentials when origin defaults to the wildcard

CVE-2026-54290 / GHSA-88fw-hqm2-52qc

More information

Details

Summary

With credentials: true and no explicit origin (the default wildcard), the CORS Middleware reflects the request's Origin and sends Access-Control-Allow-Credentials: true. Any site can then make credentialed cross-origin requests and read the responses, exposing cookie-authenticated endpoints to arbitrary origins.

Details

The spec forbids Access-Control-Allow-Origin: * with credentials and browsers reject it, so this configuration used to fail closed. In affected versions the middleware reflects the request Origin instead, so it now succeeds for every origin, including null. The preflight also echoes the requested headers back, approving non-simple credentialed requests too.

This issue arises when an application enables credentials: true and leaves origin unset or set to the wildcard.

Impact

Any third-party page a logged-in user visits can read the application's cookie-authenticated endpoints and perform credentialed state-changing requests. This affects applications that enable credentialed CORS without restricting origin.

Severity

  • CVSS Score: 7.1 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

hono: Lambda@Edge adapter keeps only the last value of a repeated request header, dropping the rest

CVE-2026-54289 / GHSA-wgpf-jwqj-8h8p

More information

Details

Summary

On AWS Lambda@Edge, CloudFront delivers a request header that appears more than once as several separate entries. The adapter writes each value with Headers.set instead of Headers.append, so every value overwrites the previous one and only the last reaches the application. Repeated request headers such as X-Forwarded-For, Forwarded, and Via are silently truncated to a single value.

Details

A repeated request header carries an ordered list of values. The adapter iterates the list but overwrites on each step, keeping only the final value. Middleware that depends on the full list — for example IP restriction that walks the X-Forwarded-For chain, or auditing based on Forwarded/Via hops — receives incomplete data. The API Gateway adapter already appends repeated values and is not affected.

This issue arises only on Lambda@Edge deployments, for requests that contain the same header more than once.

Impact

Request middleware sees only the last value of a repeated header instead of the full chain. For applications that base access control on the X-Forwarded-For chain, this can weaken or alter that decision; for auditing, hop history is lost. This affects applications deployed on AWS Lambda@Edge that rely on multi-value request headers.

Severity

  • CVSS Score: 4.8 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

hono: Body Limit Middleware can be bypassed on AWS Lambda by understating Content-Length

CVE-2026-54288 / GHSA-rv63-4mwf-qqc2

More information

Details

Summary

The Body Limit Middleware trusts the request's Content-Length header to decide whether a body is within the limit. On AWS Lambda (API Gateway v1/v2, ALB, VPC Lattice, and Lambda@Edge) the body is delivered fully buffered and the adapter builds the request with the client-declared Content-Length, which need not match the actual payload. A client can declare a tiny Content-Length while sending a much larger body, slipping past the limit.

Details

When Content-Length is present and Transfer-Encoding is absent, the middleware compares the declared value against the limit and passes the request through if it is small enough. On standards-based runtimes the transport enforces that Content-Length matches the body, so this is safe. The Lambda adapters instead reconstruct the request from a buffered payload and copy the client's Content-Length verbatim, so the declared length and the real body size are decoupled.

This issue affects applications deployed on AWS Lambda that rely on the Body Limit Middleware to cap request body size.

Impact

The declared body-size limit can be bypassed: a handler reads a payload larger than the configured maximum. Processing the oversized payload (large JSON, multipart, etc.) consumes additional CPU and memory per request. The payload remains bounded by the platform's request size limits, and Lambda isolates invocations, so the impact is increased per-request resource usage rather than full denial of service. This affects applications deployed on AWS Lambda that use the Body Limit Middleware.

Severity

  • CVSS Score: 6.5 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

hono/jsx does not isolate context per request, leading to cross-request data disclosure

CVE-2026-59896 / GHSA-hvrm-45r6-mjfj

More information

Details

Summary

hono/jsx did not isolate context values per request during server-side rendering. While an async component was suspended on await, its provided context value stayed observable to other requests rendering concurrently, so useContext() could return a value from a different in-flight request.

Details

During server-side rendering, context values were kept in a process-wide structure rather than scoped to each request's render. While an async component awaited, another request entering the same provider could observe or replace the value; when the first render resumed, it could read the other request's context.

This affects the usual ways request-scoped data is passed through a server-rendered JSX tree:

  • createContext() / useContext()
  • the jsxRenderer middleware and useRequestContext()

It arises only when context is read after an await inside an async component while requests render concurrently. Reading context synchronously (before any await), purely synchronous rendering, and client-side (DOM) rendering are not affected.

Impact

Under concurrent requests, a response could be rendered with another request's context. A user may receive HTML rendered for a different user, and an authorization check performed after an await may be evaluated against another user's data.

This may lead to:

  • disclosure of rendered output intended for another user
  • authorization decisions made with the wrong request's context
  • cross-request mixing of session or other request-scoped state

Severity

  • CVSS Score: 6.5 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Hono: API Gateway v1 adapter can drop a distinct repeated request header value during de-duplication

CVE-2026-59897 / GHSA-xgm2-5f3f-mvvc

More information

Details

Summary

The AWS API Gateway v1 adapter can drop a distinct repeated request header value. When a header appears multiple times, the adapter de-duplicates values using a substring comparison instead of an exact match, so a value that is a substring of another value of the same header is omitted (for example, 203.0.113.1 is dropped when another value is 203.0.113.10).

Details

A repeated request header carries an ordered list of values. Middleware or application logic that depends on the complete list — such as IP restriction that walks the X-Forwarded-For chain, rate limiting, audit logging, or proxy-chain validation — can therefore receive incomplete data that differs from what the client actually sent.

This issue arises on deployments using the AWS API Gateway v1 adapter (the same pattern also affects the VPC Lattice adapter), for requests that contain the same header more than once.

Impact

An attacker can craft repeated header values so that one value is omitted before the application sees the request. Where a security or routing decision relies on the full chain, this can alter that decision.

This affects applications deployed through Hono's AWS API Gateway v1 (or VPC Lattice) adapter that rely on the complete set of repeated request header values.

Severity

  • CVSS Score: 4.8 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Hono: Server-Side XSS via JSX Escaping Bypass in cx() Utility

CVE-2026-59895 / GHSA-w62v-xxxg-mg59

More information

Details

Summary

cx() in hono/css composes class names from plain strings but marks the result as already-escaped without HTML-escaping the input. When the result is used as a JSX class attribute during server-side rendering, the value is written into the attribute unescaped, so untrusted input can break out of the class attribute and inject arbitrary markup, leading to Cross-Site Scripting (XSS).

Details

Because the composed value is treated as pre-escaped, the HTML attribute escaping normally applied to interpolated values is skipped, and characters such as " pass through unescaped — allowing a value to terminate the attribute and add further attributes or elements. This arises when an application passes untrusted, user-controlled input as a class name to cx(), for example when merging a base class with an externally provided className.

Impact

During server-side rendering, an attacker who controls a value passed to cx() can inject arbitrary HTML into the page, resulting in stored or reflected XSS in the victim's browser.

This may lead to:

  • Execution of attacker-controlled script in the victim's browser session.
  • Session hijacking, credential theft, or actions performed on behalf of the victim.

Applications are affected only if they render JSX server-side and pass untrusted input as a class name to cx().

Severity

  • CVSS Score: 6.1 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Release Notes

honojs/hono (hono)

v4.12.27

Compare Source

Security fixes

This release includes fixes for the following security issues:

hono/jsx does not isolate context per request

Affects: hono/jsx, hono/jsx-renderer. During SSR, context was stored process-wide instead of per request, so useContext()/useRequestContext() read after an await in an async component could return another concurrent request's value — leading to cross-request data disclosure or authorization checks against the wrong request. GHSA-hvrm-45r6-mjfj

Server-Side XSS via JSX escaping bypass in cx()

Affects: hono/css. cx() marked its composed class name as already-escaped without escaping the input, so untrusted input passed as a class name could break out of the JSX class attribute during SSR and inject markup (XSS). GHSA-w62v-xxxg-mg59

API Gateway v1 adapter can drop a repeated request header value

Affects: hono/aws-lambda. The API Gateway v1 (and VPC Lattice) adapter de-duplicated repeated header values by substring instead of exact match, dropping a value that is a substring of another (e.g. 203.0.113.1 dropped when 203.0.113.10 is present) — affecting logic such as X-Forwarded-For-based IP restriction. GHSA-xgm2-5f3f-mvvc

Users of hono/jsx/hono/jsx-renderer, hono/css (cx()), or the hono/aws-lambda API Gateway v1 / VPC Lattice adapters are encouraged to upgrade.

v4.12.26

Compare Source

What's Changed

Full Changelog: honojs/hono@v4.12.25...v4.12.26

v4.12.25

Compare Source

Security fixes

This release includes fixes for the following security issues:

CORS Middleware reflects any Origin with credentials when origin defaults to the wildcard

Affects: hono/cors. Fixes the wildcard origin reflecting the request Origin and sending Access-Control-Allow-Credentials: true when credentials: true is set without an explicit origin, where any site a logged-in user visited could make credentialed cross-origin requests and read responses from cookie-authenticated endpoints. GHSA-88fw-hqm2-52qc

Body Limit Middleware can be bypassed on AWS Lambda by understating Content-Length

Affects: hono/body-limit on AWS Lambda (hono/aws-lambda, hono/lambda-edge). Fixes the request being built with the client-declared Content-Length while the body is delivered fully buffered, where a client could declare a small Content-Length with a much larger body and slip past the configured size limit. GHSA-rv63-4mwf-qqc2

Path traversal in serve-static on Windows via encoded backslash (%5C)

Affects: serveStatic on Windows (Node, Bun, Deno adapters). Fixes the path guard allowing a lone backslash, where an encoded backslash (%5C) decoded to \ was treated as a separator by the Windows path resolver, letting a single URL segment escape into a middleware-guarded subtree. GHSA-wwfh-h76j-fc44

AWS Lambda adapter merges multiple Set-Cookie headers into one value, dropping cookies on ALB single-header and Lattice

Affects: hono/aws-lambda. Fixes multiple Set-Cookie response headers being joined into one comma-separated value for ALB single-header responses and VPC Lattice v2, where the value could not be split back into individual cookies and clients silently dropped or misparsed them. GHSA-j6c9-x7qj-28xf

Lambda@​Edge adapter keeps only the last value of a repeated request header, dropping the rest

Affects: hono/lambda-edge. Fixes repeated request headers being written with overwrite instead of append, where only the last value of a header such as X-Forwarded-For reached the application and the remaining values were silently dropped. GHSA-wgpf-jwqj-8h8p

v4.12.24

Compare Source

What's Changed

Full Changelog: honojs/hono@v4.12.23...v4.12.24

v4.12.23

Compare Source

What's Changed

Full Changelog: honojs/hono@v4.12.22...v4.12.23

v4.12.22

Compare Source

What's Changed

New Contributors

Full Changelog: honojs/hono@v4.12.21...v4.12.22

v4.12.21

Compare Source

Security fixes

This release includes fixes for the following security issues:

app.mount() strips mount prefix using undecoded path, causing incorrect routing for percent-encoded paths

Affects: app.mount(). Fixes prefix stripping using the raw URL pathname instead of the decoded path, where percent-encoded characters in the mount prefix or path could cause the prefix to be removed at the wrong position, resulting in the sub-application receiving an incorrect path. GHSA-2gcr-mfcq-wcc3

IP Restriction bypasses static deny rules for non-canonical IPv6

Affects: hono/ip-restriction. Fixes IP address comparison using string equality, where non-canonical IPv6 representations of a denied address — such as compressed forms or hex-notation IPv4-mapped addresses — could bypass static deny rules. GHSA-xrhx-7g5j-rcj5

Cookie helper does not sanitize sameSite and priority, allowing Set-Cookie injection

Affects: hono/cookie. Fixes missing validation of sameSite and priority options against injection characters (;, \r, \n), where user-controlled input passed to either option could inject additional attributes into the Set-Cookie response header. GHSA-3hrh-pfw6-9m5x

JWT middleware accepts any Authorization scheme, not only Bearer

Affects: hono/jwt, hono/jwk. Fixes missing scheme validation in the Authorization header, where any two-part header value was accepted regardless of the scheme name, allowing non-Bearer schemes to pass JWT authentication. GHSA-f577-qrjj-4474

Users who use app.mount(), hono/ip-restriction, hono/cookie, or hono/jwt/hono/jwk are encouraged to upgrade to this version.

v4.12.20

Compare Source

What's Changed

New Contributors

Full Changelog: honojs/hono@v4.12.19...v4.12.20

v4.12.19

Compare Source

What's Changed

New Contributors

Full Changelog: honojs/hono@v4.12.18...v4.12.19

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@cloudflare-workers-and-pages

cloudflare-workers-and-pages Bot commented Aug 5, 2026 •
edited
Loading

Copy link
Copy Markdown

Deploying stackhacker-ui-web with  Cloudflare Pages  Cloudflare Pages

Latest commit: da06185
Status: ✅  Deploy successful!
Preview URL: https://fc7f916c.stackhacker-ui-web.pages.dev
Branch Preview URL: https://renovate-npm-hono-vulnerabil.stackhacker-ui-web.pages.dev

View logs

@hirotaka hirotaka closed this Aug 6, 2026
@hirotaka
hirotaka deleted the renovate/npm-hono-vulnerability branch August 6, 2026 03:14
@renovate

renovate Bot commented Aug 6, 2026

Copy link
Copy Markdown
Contributor Author

Renovate Ignore Notification

Because you closed this PR without merging, Renovate will ignore this update (4.12.27). You will get a PR once a newer version is released. To ignore this dependency forever, add it to the ignoreDeps array of your Renovate config.

If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@hirotaka